This invention relates to a method and apparatus for use with software programs and, in particular, to a method and apparatus for controlling operation and control block management of these programs.
In computer operating systems in use today, the programs of the systems are often segmented into layers each of which contains a group of self-contained functions or procedures. Each such layer shall be referred to herein as a Layered Procedure Set or LPS.
A basic model governing the communication of messages between and the invoking of LPSs in computer programs is the so-called queued "Scheduler-Dispatcher" model. This model is widely used in the data processing industry, especially in data communications. A particular data communications version of a Scheduler-Dispatcher model is described in Appendix C of IBM's SNA Format & Protocol Reference: Architectual Logic.
In the queued Scheduler-Dispatcher functionality, message event blocks (MEBs) are used in conjunction with the Scheduler, Dispatcher and LPSs. MEBs provide an internal storage medium consistent enough in form to be able to pass messages identified as events and their associated control information from place to place within a program, and especially through the Scheduler and Dispatcher and between LPSs.
In one version of the Scheduler-Dispatcher model, the Scheduler functions as a loop within a procedure. The Scheduler loop first waits on interrupts within the system and when an input/output ("I/O") procedure completes, identifies an associated MEB on its ready queue ("READY Q"), dequeues the MEB and enqueues it to the queue of the Dispatcher ("DISPATCH Q") and calls the Dispatcher. The Scheduler also acts on receiving control back from the Dispatcher to check its Ready Q and, if the READY Q contains an MEB, the Scheduler dequeues the MEB from the READY Q and enqueues it to the DISPATCH Q and calls the Dispatcher. If the READY Q is empty, however, the Scheduler checks the queue of the I/O ("I/O Q"). If there is an MEB on the I/O Q, the Scheduler dequeues the MEB and passes it as a parameter for execution of the I/O procedure.
When the Dispatcher is called by the Scheduler, the Dispatcher dequeues an MEB from its DISPATCH Q and calls the LPS associated with the destination contained in the MEB, passing the MEB as a parameter. When control is returned to the dispatcher from the LPS, the Dispatcher checks the DISPATCH Q to determine whether any MEBs are present. If the DISPATCH Q is empty, it returns control to the Scheduler. If the DISPATCH Q is not empty, the Dispatcher repeats its procedure until the DISPATCH Q is empty at which time It then returns control to the Scheduler for repeat of the Scheduler procedure.
In the above operation of the Scheduler-Dispatcher model, the Scheduler, if there are no MEBs in the READY Q, checks the I/O Q to determine whether there are any MEBs present in this queue. If so, the Scheduler dequeues the MEB from the I/O Q to initiate execution of an I/O procedure. This is accomplished by an I/O handler ("I/O Handler") which begins execution upon a call from the Scheduler. This call is accompanied by passing of the MEB. Once the I/O handler has initiated the I/O operation, it returns control immediately to the Scheduler. To complete an I/O, the Scheduler invokes the I/O Handler by a call to the procedure wait on interrupt. The I/O Handler then checks for completion interrupts for the I/O operation (e.g., hitting of a key by a user). If a completion interrupt has occurred, the I/O Handler locates the MEB associated with that I/O, updates the MEB and enqueues it to the READY Q. If a completion interrupt has not occurred, the I/O Handler suspends processing and the process is idle until a completion interrupt actually OCCURS.
The call by the Scheduler to the wait on interrupt procedure is completed when the I/O Handler returns control to the Scheduler. At this point, the Scheduler falls through, i.e., returns to, its READY Q loop procedure. In particular, the Scheduler initiates the LPS portion of its processing cycle by dequeuing the completed and updated MEB from the I/O operation in its READY Q, enqueuing the EMB to the Dispatch Q and then calling the Dispatcher.
The LPS structure and the Scheduler-Dispatcher model with I/O Handler and MEBs is of considerable use in controlling execution and operation and control block management and storage in programs. It is particularly advantageous where the level of complexity of a program is such as to require the utilization of multiple LPSs for the purpose of modularity. It is also advantageous where multiple sessions are to be executed concurrently within the same program. As used herein, a session within a program may be thought of as one or more multi-threaded tasks intended to be completed as a unit. This unit, however, will not be executed continuously from start to finish and the execution of units of several sessions may be occurring concurrently. As an example, the tasks associated with the operation of a single terminal may be considered as a session, while the tasks associated with the operation of multiple terminals may be considered as multiple sessions. A typical example of a program requiring the LPS and Scheduler-Dispatcher structure might be a data communications program (e.g., SNA or OSI) where there are formally architectured functional divisions of labor and where there are many devices (terminals, remote computer systems, disk resources) which are being serviced simultaneously.
While the LPS structure is highly advantageous, the manner of storage and management of the control blocks, both MEBs and layer control blocks ("CBs") which store control and other information associated with the LPSs, permits programming which can have undesired results. A typical data structure for such storage and management of MEBs and CBs is described and shown on page 8 of Appendix A of the aforementioned IBM reference. As shown by the illustrated Node Control Block (equivalent to an MEB), all the CBs are attached directly to the Node Control Block, are rigidly set forth or typed, and all CBs of all the layers (the equivalent of LPSs) are freely available to any other layer.
With this type of storage and management for the CBs, it becomes possible for one LPS to access and alter the content of the CB of another LPS. Such alteration, if it occurs, can have a detrimental effect on program operation, since the second LPS may need its unaltered CB in continuing a procedure. It also inhibits so-called "information hiding", which has been found to be beneficial to program operation and management.
It is, therefore, an object of the present invention to provide a method and apparatus for program control and operation which tends to mitigate the aforesaid disadvantages.
It is a further object of the present invention to provide a method and apparatus for program control in an LPS architectured system which is structured to establish privacy of each CB with respect to its LPS.
It is a further object of the present invention to provide a method and apparatus for program control in an LPS architectured system wherein access of an LPS to a CB of another LPS is inhibited.
It is yet a further object of the present invention to provide a method and apparatus for program control in an LPS architectured system wherein information hiding is promoted.